1Passwordを利用したSSH時のToo many authentication failuresを回避する
2024.05.27SSHキーを1Passwordに保存しておき、
~/.ssh/configに
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1Password/t/agent.sock"
という設定を書いておくと秘密鍵を1Passwordから出すことなくサーバに接続することができます。 こちらの内容については下記ブログなどをご参照ください。
https://dev.classmethod.jp/articles/1Password-git-ssh/
私はこの方法を愛用していたのですが、 ある日次のエラーが出るようになりました。
Received disconnect from UNKNOWN port 65535:2: Too many authentication failures Disconnected from UNKNOWN port 65535
内容としては、許容されるパスワード試行回数をオーバーしたために認証に失敗しているようです。 調べてみると、なんと、 1Passwordは登録されているSSHキーをある一定の順番で頭から順に試していくという実装になっているようです。 そして登録されているSSHキーがサーバが許容する試行回数を超えると、 運悪く最後の方に正解がある場合でも、 それを試行することなくエラーとなってしまうようです。
上述した~/.ssh/configに書くIdentityAgentは全ての接続に対して共通の文字列を書きます。
どのキーを使うにしても同一の文字列を書くという仕様なので、
どうやって正しいキーを見つけているのだろう？
と思っていましたが、まさかこれほど単純な仕組みだとはちょっと驚きました。
さて「この接続先の時はこのキーを使う」と指定するということができたので、 その方法について共有したいと思います。
やりかた
基本的なやり方はドキュメントに記載があります。
Advanced use cases | 1Password Developer
にある通り、秘密鍵から作成される公開鍵をダウンロードして任意の場所に配置します。
そして、この公開鍵ファイルの場所を~/.ssh/configに次のように書き加えます。
IdentityFile "~/.ssh/sample-server.pub"
よって~/.ssh/configの全体像はこんな感じになります。
Host sample-server HostName xxx.xxx.xxx.xxx User ec2-user IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" IdentityFile "~/.ssh/sample-server.pub"
私見ですが、 ここで公開鍵ファイルを配置しなければならないのはちょっと惜しい感じですね。 せっかく秘密鍵を1Passwordから一切出さずに済むようになったので、 ここは是非公開鍵も置く必要がないようにして欲しい所です。
基本的にはこれで SSHコマンドを施行する際に使用する秘密鍵を指定することができます。
しかし、私のケースではこれだけではうまくいかず、 次の設定も必要でした。
agent.tomlの設定
下記ファイルを設定する必要がありました。
~/.config/1Password/ssh/agent.toml
SSH agent config file | 1Password Developer
このファイルは1Password側の設定ファイルです。
（さっきの~/.ssh/configはあくまでもSSHの設定であり、
1Passwordは直接は無関係）
そもそも接続できなかった原因は、
1Passwordが登録されているSSHキー全てが探索対象に入っていなかったことのようです。
1PasswordにはVaultという概念がありますが、
どうやらagent.tomlの設定がない場合はデフォルトのVaultしか探索対象とならないようです。
私が使いたかったSSHキーは特定のVaultに格納されているものだったので、
デフォルトしか見ない状態では接続ができませんでした。
設定を書いてみる
ドキュメントを見ると、ここには3階層の設定を書くことができます。
- item
- vault
- account
上のものほど細かい粒度、下ほど大雑把な括りとなります。
itemは個々のSSHキーを指定します。
vaultはVault単位で指定、accountはアカウント単位での指定となり、
それらを指定するとそこに属す全てのSSHキーが選択肢に含まれるようになるようです。
私の場合は
[[ssh-keys]] account = "（アカウント名）"
という風にアカウントを指定したところ、 どのVaultに存在しているかに依らず、 1Passwordに存在する全てのSSHキーが探索対象に選ばれるようになりました。
この状態であればSSHは公開鍵の情報からどの秘密鍵を使うべきかを知ることができ、 無事サーバに接続することができました。
そして、この方法であれば、 当てずっぽうなパスワードの試行も行われなくなっているはずです。
どのSSHキーが探索対象なのか確認する
設定としては以上ですが、 今どのSSHキーが探索対象になっているのかを確認する方法も紹介します。
ドキュメントに書いてある通り、
$ SSH_AUTH_SOCK="$HOME/Library/Group Containers/2BUA8C4S2C.com.1Password/t/agent.sock" ssh-add -l
というコマンドで、 現在どのSSHキーが探索される対象なのかを調べることができます。
全てのキーを探索対象とした環境ではこんな出力でした。（イメージ）
$ SSH_AUTH_SOCK="$HOME/Library/Group Containers/2BUA8C4S2C.com.1Password/t/agent.sock" ssh-add -l 2048 SHA256:ow9Un8BBvEM743GYcatfW6U6ej5LD8mTBdh0MgpfWdE keypair-01 (RSA) 2048 SHA256:jQbSYd0uj9wbvJU4OaRxyzucfo8AKRsNiraBjwEVdew keypair-02 (RSA) 3072 SHA256:qAwU3wGibzvGwCqrrPLgk/iyf/emOar4pYgQ1iriv1I keypair-03 (RSA) 2048 SHA256:rLA0HH1qSvsQjI9B4iLFEfucc/FCoghoyeXZcao7VCk keypair-04 (RSA) 2048 SHA256:+GNPpbM8AX8C/IDHLGu8BKMLrp26qvHlYgbl8PklcWI keypair-05 (RSA) 3072 SHA256:qAwU3wGibzvGwCqrrPLgk/iyf/emOar1pYgQ1iriv1I keypair-06 (RSA) 2048 SHA256:Y2GWuzT8Nnm1zEU4dvU5iqlsOFoBTtnxbPE4WXpaTxM keypair-07 (RSA) 2048 SHA256:E1raQDSApnidnRDSVQ3LeMOKNhxDdfbVHJL4fwlpF4U keypair-08 (RSA) 2048 SHA256:nYhtRKATuEtoezt6uFLOZSbOfNfredhoIASa8OLmbmU keypair-09 (RSA) 2048 SHA256:BIA+knIX+P7ScdahSTK0CcPdMYPd1Q3NixiTtUEPSa0 keypair-10 (RSA) 2048 SHA256:D+xkoJ+x/jEwNsO0EXSKODAAWyHNfdxISZmo0mTyRQM keypair-11 (RSA)
ここで探索対象を特定のVaultやItemだけに絞ると、 このコマンドの出力もそれに従ってフィルターされていることが確認できます。
注意点
agent.tomlに関しては、ちょっと混乱を招く注意点があります。
それは、
~/.config/1Password/ssh/agent.tomlファイルが存在しないこと- ファイルの中身がカラ（全てコメントアウトされた場合を含む）
は別の設定となる、ということです。
上で述べた「デフォルトのVaultのみが参照される」というのは ファイル自体が存在しない場合の挙動です。 一方ファイルの中身がカラ（ファイル自体は存在）の場合は 「どのアカウント、Vault、Itemも参照しない」を意味します。 よってSSH接続は実質機能しません。
これは地味につまずくポイントかなと思いました。
まとめ
1PasswordのSSHキーを大量に登録するとToo many authentication failuresが発生することに対しての対応策をご紹介しました。
本文中にも書きましたが、
公開鍵ファイルを配置しなければいけない点が少し残念に思えます。
~/.ssh/configはSSHのファイルなので1Password側の勝手な都合に合わせることはできませんが、
agent.tomlは1Passwordの設定ファイルなので、
ここに何かキーワードを指定するような設定にできたら嬉しかったな〜と思いました。
とは言え、これでSSHを大量に登録してもきちんとSSH接続ができますし、 表面的に見えないとはいえ、 間違ったパスワードを何度も試行しているという状態も回避できるので 精神衛生的にかなり良いです。 この目的のためだけでも、この方法を導入する価値はあるかなと思いました。
以上、誰かの参考になれば幸いです。
